Harness Engineering 到底是什么？概念、实战与争议，一次全部讲清楚

本文基于 YouTube 视频 整理，力求不遗漏任何细节。

一、背景：从 Prompt Engineering 到 Context Engineering 再到 Harness Engineering

继 Prompt Engineering、Context Engineering 之后，AI 圈最近又冒出了一个新名词——Harness Engineering。从 2025 年 2 月开始，这个词频繁出现：

  • OpenAI 专门发文，讲他们如何用 Harness Engineering 在 5 个月内写了将近 100 万行代码；
  • Anthropic 紧接着发文，分享自己如何使用精心设计的 Harness 架构来驱动 Agent 的开发应用；
  • 连技术大牛 Martin Fowler 创立的技术网站 martinfowler.com 也开始公开讨论 Harness Engineering。

但与此同时，也有不少人认为这不过是个噱头，换汤不换药。本文就来把这个事情彻底搞明白。

二、前置概念：Prompt Engineering 与 Context Engineering

在讲 Harness Engineering 之前，先回顾它的两个”前任”。

2.1 Prompt Engineering：怎么把话说清楚

Prompt = 用户发给大模型的话。Prompt Engineering 就是一门研究怎么把这句话说清楚的技术。

举例：向大模型发问”帮我的猫起个名字”，大模型可能回答”花花””小白”——但这些名字可能都不满意，因为你家的猫是橘色的，”花花”和”小白”都与橘色冲突。

问题出在 Prompt 上——没有给大模型充足的信息。按照 Prompt Engineering 的理念，重新设计 Prompt：

帮我的橘色小猫起名，两个字，需要体现出它活泼爱玩的性格

大模型就能给出更贴切的名字，比如”橘宝”（橘色的大活宝）、”橙豆”（橙色的小豆子，小豆子掉地上蹦蹦跳跳，也体现活泼性格）。

Prompt Engineering 本质：调整大模型提示词的技术。如今已很少被单独提起——一方面门槛太低，另一方面模型本身能力变强，很多时候不需要在 Prompt 上调来调去。

2.2 Context Engineering：怎么给信息

继续用小猫举例：拿到名字后继续跟大模型聊天，问”那它平时吃什么好呢？”——这个就是新的 Prompt。但此时发给大模型的不仅有这个 Prompt，还有之前的对话历史，这样大模型才知道新问题里的”它”指代的是什么。

无论是 Prompt 还是对话历史，都是大模型所接收到的信息，统称为 Context。Context 还包含工具列表、Skill 列表等。

Context 有容量上限，所以不可能无止境地往里塞东西，需要精心设计 Context 里面的内容——这就是 Context Engineering。

Context Engineering 的经典方法：

  • 上下文压缩：当对话历史超过某个阈值时，对之前的对话历史做总结，防止 Context 内容过多影响回答效果；
  • 动态检索外部资料；
  • 渐进式披露；
  • ……等等。

Context Engineering 虽然能整活，但效果有一定上限。为了进一步榨干大模型的潜力，AI 圈又整出了新花样——Harness Engineering。

三、Harness Engineering 是什么

3.1 从”马具”说起

Harness 这个词的本意是马具——套在马身上用来控制马的那些装备，比如缰绳、头套等。虽然马非常强大，但必须借助马具的力量来限制马的活动，才能让马为人类所用。

3.2 类比到 AI 领域

  • 脱掉马具的马 → 大模型（特别强，但不对它加以干预就会像脱缰野马一样发散思维，甚至产生严重幻觉，无法稳定给出想要的结果）；
  • 马具 → 用来控制大模型的系统，即 Harness。

3.3 核心公式

$$\text{Harness} = \text{Agent} - \text{Model}$$

一个完整的 Agent 减去里面的大模型，剩下的所有东西都是 Harness。

⚠️ 注意：Harness Engineering 是非常新的概念，目前业界还没有形成严格的定义，这个公式只是大多数人比较认可的说法，并非严格的学术定义。

3.4 具体例子：Claude Code

在 Claude Code 里面，所有不属于 Claude 模型的部分都是 Harness，比如：

  • 写在 CLAUDE.md 里面那些大模型要遵循的规则；
  • Claude Code 可以使用的工具；
  • 定时调度机制；
  • ……等等。

总而言之：只要不是模型，都可以将它视为 Harness 的一部分。

3.5 Harness Engineering 的定义

Harness Engineering = 一门专门研究如何构建与设计 Harness 的技术。换句话说：除了大模型本身不研究，别的什么都研究。

它不再是紧紧盯着模型输入的那点提示词或上下文，而是站在更高的系统层面上，研究怎么给大模型设计一套可以稳定运行的系统，让大模型踏踏实实地为人类做事。

3.6 三者关系：层层递进

层级 关注问题 研究范围
Prompt Engineering 怎么问问题 如何组织 Prompt，把话说得更清楚、更准确
Context Engineering 怎么给信息 最合适的时机把最合适的内容放到 Context 里（含 Prompt、对话历史、工具列表等）
Harness Engineering 怎么搭系统 围绕大模型搭建完整可靠的 Agent（权限管控、工具管理等）

四、OpenAI 的 Harness Engineering 实战

4.1 疯狂实验：AI 从零写一个生产系统

2025 年 8 月，OpenAI 内部启动了一个疯狂的实验：用 AI 从零开始写一个真实的软件产品，全程不允许工程师手写一行代码。

产品的所有组成部分都由 AI 生成，包括：

  • 业务逻辑
  • 测试
  • CI 配置
  • 文档
  • 内部工具

靠着 AI，项目代码规模直接干到了将近 100 万行，而且这是一个真正在线上跑、有真实用户的生产系统。总体耗时只用了 5 个月左右，团队规模一开始 3 个人主导，后来扩张到 7 个人。算下来开发效率差不多是纯人工的 10 倍。

4.2 实验一开始并不顺利

有意思的是，实验一开始的进展并不顺利——不是因为大模型不够聪明，而是因为 Harness 没有搭建好。

早期阶段，团队只是简单地把任务交给 Codex（OpenAI 的编程 Agent），然后让 Codex 自己去写代码。但结果很差：代码质量低、经常偏离需求、甚至产生幻觉。团队反复尝试调整 Prompt，但效果始终不理想。

关键转折点：团队意识到问题不在 Prompt，而在于整个系统设计。他们需要围绕 Codex 搭建一套完整的支撑体系——这就是 Harness。

4.3 OpenAI 的 Harness 设计

OpenAI 围绕 Codex 搭建了以下关键 Harness 组件：

4.3.1 AGENTS.md：项目规范文件

OpenAI 为每个项目创建了一个 AGENTS.md 文件，里面写满了项目级别的规范，包括：

  • 代码风格要求
  • 架构决策
  • 依赖管理策略
  • 测试要求
  • ……等等

这个文件就像给 Codex 定的”家规”，让它在写代码时有据可依，而不是随意发挥。

4.3.2 代码质量检查（Linter + Type Checker）

OpenAI 在 Harness 中集成了严格的代码检查工具。每次 Codex 写完代码，Linter 和 Type Checker 就会自动检查代码质量。如果发现问题，就会把错误信息反馈给 Codex，让它自动修复。

这个机制非常关键——它相当于给 Codex 装上了一面”镜子”，让它能看到自己代码的问题并自我纠正，而不是把错误留到后面。

4.3.3 自动化测试

OpenAI 采用了**测试驱动开发（TDD）**的方式：先让 Codex 写测试用例，再让它写实现代码。这样每次代码变更都能通过测试来验证正确性。

4.3.4 CI/CD 流水线

完整的持续集成和持续部署流水线，确保每次代码提交都经过完整的验证流程。

4.3.5 权限管控

沙箱机制和安全边界，限制 Codex 的操作范围，防止它做出破坏性的操作。

4.4 效果：从混乱到高效

搭建好 Harness 之后，Codex 的表现发生了质变：

  • 代码质量大幅提升
  • 需求偏离的情况显著减少
  • 幻觉问题得到有效控制
  • 开发效率达到纯人工的 10 倍

OpenAI 在文章中总结道：Harness Engineering 的核心不在于让模型更聪明，而在于给模型创造一个能让它稳定发挥的环境。

五、Anthropic 的 Harness Engineering 实战

5.1 核心架构：Planner + Generator + Evaluator

Anthropic 提出了一套经典的三 Agent 架构：

5.1.1 Planner（规划 Agent）

负责将大任务拆解为一系列功能点（feature），形成执行计划。

5.1.2 Generator（生成 Agent）

根据 Planner 的计划，逐个功能点实现代码。

5.1.3 Evaluator（评估 Agent）

对 Generator 产出的代码进行质量评估和正确性检查。如果不通过，就反馈给 Generator 重新生成；如果通过，则产出最终结果。

5.2 具体实践细节

5.2.1 上下文焦虑问题

问题：Sonnet 4.5 存在”上下文焦虑”——当上下文过长时，模型会急于结束任务，以更少的 token 完成交付，影响最终质量。

Harness Engineering 解决方案：Anthropic 使用了上下文重置技术来解决这个问题——在上下文过长时，对上下文进行重置或压缩，让模型重新聚焦。

后续演进：当模型升级到更强的 Opus 4.5 后，这种现象被大幅缓解，因为 Opus 4.5 没有明显的上下文焦虑问题了，也就不怎么需要这方面的 Harness 设计了。

5.2.2 长任务执行效果差

问题：在长任务中，Generator 容易偏离轨道或遗漏功能点。

Harness Engineering 解决方案：Anthropic 在提示词里面强制 Generator 每次只选取一个功能点，做完一个再做下一个，确保整个产品开发流程稳步向前推进。Evaluator 也对每个功能点分别评估。

后续演进：用到更强的 Opus 4.6 之后，这种强制分步执行的机制就不需要了——Opus 4.6 的全局统筹能力够强，可以一次把所有功能点都拿过来，自己决定先做哪个再做哪个，稳步推进，不需要别人对它的执行流程指指点点。Evaluator 也直接评估最终产出就可以了，不需要再分功能点评估。

5.3 Anthropic 的 Harness 设计文章

Anthropic 发了两篇重要文章：

  1. Effective Harnesses for Long-Running Agents（2024 年 11 月）——讨论如何为长时间运行的 Agent 设计有效的 Harness；
  2. Harness Design for Long-Running Application Development（2025 年 3 月 24 日）——拿出了 Planner、Generator 和 Evaluator 的经典架构。

值得注意的是，Anthropic 自己比较克制，通篇依然只用了 Harness 这个名词，并没有生搬硬套 Harness Engineering 这个刚刚炒热的新词。但在当时的氛围下，整个 AI 圈心照不宣，直接就把这套三 Agent 架构当成了 Harness Engineering 的教科书级案例。

六、Harness Engineering 的来源与传播

6.1 Harness 这个词本身并不新

单就 Harness 这个词来说，它并不算是一个彻头彻尾的新词。一般大家用它来指代为了支持某个功能所做的一套框架。

  • 传统软件测试领域：有 Test Harness 的概念——为了支持测试代码运行而做的一套框架（包含测试运行器、测试环境等）；
  • AI 领域：开源项目 lm-evaluation-harness——为了支持模型效果评估而做的一套框架；
  • Anthropic 去年 11 月的文章：Effective Harnesses for Long-Running Agents——Harness 代表为了支持 Agent 长时间运行而做的一套框架。

所以 Harness 这个概念一直都在，大家也都在默默用，谁也没觉得这是个需要大吹特吹的新概念。

6.2 “Harness Engineering” 这个组合词的诞生

Harness Engineering 把这两个词组合在一起，是最近才发生的事。

6.2.1 起点：Mitchell Hashimoto（2025 年 2 月 5 日）

目前比较公认的起点是 Mitchell Hashimoto 的博客文章 “My AI Adoption Journey”。Mitchell Hashimoto 在海外技术圈是响当当的人物，很多大公司的底层工具都是他做的。

他在博客里写道：

我也不知道业界有没有公认的叫法，我就姑且管它叫 Harness Engineering。它的核心理念就是：只要 Agent 犯了错，你就去改造系统，让它绝不再犯同样的错。 要是有更好的词，我随时改口。

所以这个词的起点其实非常朴素，甚至带着点随意，跟后来大家讨论的宏大概念还是有区别的。

6.2.2 引爆：OpenAI（2025 年 2 月 11 日）

真正引爆这个概念的是 OpenAI 发的那篇 Harness Engineering 文章。这篇文章信息量极大，迅速在业界引起了巨大反响。

耐人寻味的细节（martinfowler.com 文章指出）：虽然 OpenAI 这篇文章的标题有 Harness Engineering 这两个词，但如果你仔细去翻 OpenAI 的文章，正文里其实只提了一次 Harness 这个词。因此推测 OpenAI 搞不好就是受了 Mitchell Hashimoto 的启发，事后才临时把 Harness Engineering 这个词放到了标题里面。

6.2.3 跟进讨论：martinfowler.com（2025 年 2 月 17 日）

仅仅 6 天后，软件工程界鼎鼎大名的 Martin Fowler 网站（martinfowler.com）就发了一篇文章，作者是 Thoughtworks 里一位非常资深的工程师，文章标题叫 Harness Engineering - First Thoughts——就是她读完 OpenAI 那篇文章之后的第一反应。作为顶级技术博客，这篇文章一发出来自然就在圈内引发了广泛讨论。

她在文章里还点出了一个很耐人寻味的细节：虽然 OpenAI 文章标题有 Harness Engineering，但正文里其实只提了一次 Harness 这个词。

6.2.4 LangChain（2025 年 3 月 10 日）

LangChain 发了一篇文章叫 The Anatomy of an Agent Harness，这篇文章第一次明确给出了关于 Harness 的公式：

$$\text{Agent} = \text{Model} + \text{Harness}$$

这其实就是前面聊过的那个公式的变体（Harness = Agent - Model），两个等式本质上是一回事。公式一出，概念就算定调了。

6.2.5 Anthropic（2025 年 3 月 24 日）

Anthropic 发了那篇 Harness 的文章，拿出了 Planner、Generator 和 Evaluator 的经典架构。虽然 Anthropic 自己比较克制，通篇依然只用了 Harness 这个名词，但在当时氛围下，整个 AI 圈心照不宣，直接就把这套三 Agent 架构当成了 Harness Engineering 的教科书级案例。

就这样，一传十，十传百，Harness Engineering 从一个人的私人说法，变成了大家都在用的词。

七、Harness Engineering 是不是噱头？

7.1 复盘：没有新技术

如果你复盘完这段历史，再仔细琢磨一下，就会发现一件非常微妙的事情——Harness Engineering 里用到的所有技术，竟然没有一个是新的。

你看前面讲的 Linter 代码检查、任务拆解规划、质量评估机制——这些东西其实早就有了，很多观众甚至都在做相关工作。Harness Engineering 真正做的，只是把这些技术重新组织了下，统一放到了一个新词下面。

换句话说，它提供的是一套新的系统思维框架，而不是发明了一批颠覆性的新技术。

7.2 怀疑论者的两大攻击点

攻击点一：没有新东西，全都是”新瓶装旧酒”

在这种情况下，特意造个新词到处宣传，可不就是噱头吗？

攻击点二：所有的 Harness Engineering 都迟早要被淘汰

怀疑论者认为，随着大模型自身能力的持续进化，今天看起来必不可少的这些 Harness 设计，未来很可能会被模型能力本身逐步吸收，最终变得不再需要。

而这种担忧，其实连 Anthropic 自己的文章里都有迹可循。 前面讲过的两个案例就是明证：

  1. 上下文焦虑：Sonnet 4.5 需要用 Harness Engineering（上下文重置）来解决，但 Opus 4.5 自身就没有这个问题了；
  2. 长任务执行：早期需要强制 Generator 逐个功能点执行，但 Opus 4.6 自己就能全局统筹，不需要外部约束了。

这恰恰印证了一个非常现实的趋势：模型越强，需要的 Harness 就越少。 大模型自身的进化，正在一口一口吃掉 Harness Engineering 的生存空间。

7.3 Anthropic 官方的态度

Anthropic 官方在文章里其实没那么悲观。他们认为，随着模型变强，Harness 的形态也会跟着进化，去解锁更复杂的任务——也就是说，Harness 只会变形，不会消失。

7.4 大胆推演：如果未来的模型真的强到离谱？

这并不是说未来连读写文件、联网搜索这种基础工具都不需要了，而是说，也许只要给大模型配置上最基础的 Harness，它自己就能把剩下 99% 的问题全搞定。真到了那一天，Harness Engineering 就不再是一门需要专门去钻研的技术了，它会退化成一个单纯的环境接口、一个底层基础设施。仔细想想，这件事发生的概率恐怕没有那么低。

7.5 最终判断

Harness Engineering 不是噱头，但应该也不是终局。

说它不是噱头，是因为它已经实实在在带来了效果——无论是 OpenAI 还是 Anthropic，都通过 Harness Engineering 把 Agent 的稳定性、自动化程度和生产力往前推了一大步，这些都是可以被验证的工程成果，而不是概念炒作。

当然也有人会说它不过是”新瓶装旧酒”，用的都是老技术。但问题在于，工程领域真正的进步，往往不在于发明了什么新技术，而在于有没有一套统一的框架，把这些零散的能力组织起来，变成可以系统设计、可以持续优化的工程方法。 Harness Engineering 的意义恰恰就在这里。

但不得不承认，Harness Engineering 大概率不是终局。 随着模型能力继续增强，今天这些用来约束模型、纠正模型、给模型兜底的系统设计，很可能会被模型自身逐步吸收。到那个时候，很多 Harness 可能会变得不再必要，这个词也许会慢慢淡出大家的视野。

所以更愿意把它看成一个过渡期的关键技术。它可能不是未来的终局答案，但它是当下最现实的答案——因为回到今天，模型依然会犯错，依然会幻觉，依然会在复杂任务中偏离轨道。在这种现实下，Harness Engineering 的重要性就不容忽视——谁能把 Harness 搭得更稳，谁就能更早把 AI 的能力转化成真正的生产力，从而从中受益。

八、相关文章链接

OpenAI：

Anthropic：

LangChain：

Mitchell Hashimoto：

martinfowler.com：